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(54) Banning verbal communication to and from a selected party in a game playing system 



(57) Voice communication between players using 
one or more multiplayer game console is selectively 
controlled. A player may selectively block voice commu- 
nications with another player during a current and any 
future games. In addition, an authorized party (e.g., a 
parent) can selectively preclude voice communication 
by a minor child by setting an option that is uploaded to 
an online game service service; the minor child is then 
precluded from voice communication on any voice con- 
sole via the online game service. Also, a player may be 
temporarily or permanently banned from voice commu- 
nication during games played through an online game 
service in response to complaints made by other players 
concerning the player's behavior in voice communica- 
tion while playing games, e.g., excessive use of profan- 
ity. When a player signs on to the online game service, 
data are downloaded to the game console that indicate 
any applicable restraints on voice communication. 
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Description 

Field of the Invention 

[0001 ] The present invention generally relates to con- 
trol of verbal communication between players of an elec- 
tronic game; and more specifically, pertains to selective- 
ly preventing verbal communication between players 
who are using one or more electronic game consoles to 
play a game. 

Background of the Invention 

[0002] When playing a non-electronic game, for ex- 
ample, a card game such as bridge, with one or more 
other people, the social interaction and verbal sparring 
that arises during the game typically adds much to the 
enjoyment of the players. The verbal communication is 
also an element of game play, since comments made 
by a player to an opponent during a game can cause 
the opponent to lose concentration and perform poorly, 
while comments made to team members can provide 
encouragement, thereby promoting their quality of play. 
Communication between persons playing games is thus 
clearly an important element of the gaming experience. 
[0003] The verbal repartee between players that is so 
important to game play was missing when players first 
began to play electronic games over the Internet and 
other network links. Players at different sites were gen- 
erally not able to communicate with each other, because 
their personal computers (PCs) only communicated da- 
ta related to the play of a game over the network. The 
loss of the verbal social interaction that is so much a part 
of game play when players are all in the same room 
caused play of games over the Internet to be less inter- 
esting. To address this problem, hardware and software 
solutions were developed that support voice communi- 
cations between PCs over the network during game 
play. At about the same time, the techniques were 'de- 
veloped to convey voice over the Internet or other net- 
works (i.e., voice over IP) to enable communications be- 
tween parties connected by the network without incur- 
ring the cost of conventional telephone long distance 
calls. This work resulted in the creation of various pro- 
tocols supporting voice over IP communication, includ- 
ing the H.323 specification, Session Initiation Protocol 
(SIP), and Media Gateway Control Protocol/Media 
Gateway Controller (MGCP/MEGACO). Much of the 
functionality and techniques of voice over IP is applica- 
ble to and has been used in schemes to enable verbal 
communications over a network between players of PC 
electronic games. Examples of systems that provide 
voice communication between connected PCs during 
game play include Microsoft Corporation's SIDE WIND- 
ER GAME VOICE™, Mindmaker, Inc.'s GAME COM- 
MANDER 2™ device and software, TEAMSOUND™ 
software, GameSpy Industries' ROGER WILCO soft- 
ware, and Alienware Technology's FIRST CONACT 



2 

software. The voice communication provided by these 
products greatly adds to the enjoyment of playing 
games on PCs that are connected over the Internet or 
other networks. Some of these systems operate in peer- 

5 to-peer mode, in which voice data are transferred over 
the network directly between PCs, while others require 
a voice server that receives the voice data from one 
game player computer and forwards the data over the 
network to one or more other computers connected to 

10 the network for playing the game ft 

[0004] In contrast to a PC game system in which only 
one player is supported on each PC, a multiplayer game 
console supports a plurality of players on each console. 
Voice communication systems have been developed for 

'5 game consoles that enable verbal communications be- 
tween a plurality of players who are playing a game. The 
verbal communication can be between players on the 
same game console or between players on different 
game consoles thai are coupled in communication, ei- 

20 ther directly or over a network, such as the Internet. 
[0005] While verbal communication during game play 
is generally a desirable feature, if abused or misused by 
a specific player it may become bothersome to one or 
more other players in a game. The cause of the annoy- 

25 ance to a player may be the repeated use of profanity 
or sexually explicit language by the specific player, or 
may simply be language or comments that a player feels 
to be socially unacceptable. Since each player has an 
individual reaction to certain verbal behavior, the causes 

30 for a player to be annoyed by the verbal communication 
with a specific player are virtually unlimited. Neverthe- 
less, it will be important to enable any player who be- 
comes annoyed with the verbal communication of a spe- 
cific player to prevent further verbal communications 

35 with that specific other player. The prior art does not en- 
able a player to block verbal communication with an an- 
noying player in a specific game played on a multiplayer 
game console, or to generally block an annoying player 
from talking or listening to the player during any game 

40 played on multiplayer game consoles. 

[0006] Control of verbal communication with selected 
other players might be implemented by game software, 
to permit the control to extend only over a single game 
play session. Alternatively, the control of verbal commu- 
nication might better be applied based upon player data 
maintained at a central site, such as an online game 
service service. Each time that a player logs on through 
a game console to play a game over the network, the 
data can then be accessed to determine if verbal com- 

50 munication by one of the players or between certain 
players has been precluded. The act by a player of mut- 
ing verbal communications with a selected player during 
a game should preferably not alert the selected player 
of that decision, and should not adversely impact on the 

55 player's ability to communicate with other players in a 
game. The muting of a selected player by another player 
should remain in effect, regardless of changes in an ali- 
as or changes in the gaming device used by the selected 
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player to play games over a network. 
[0007] Parents may want to block their child from par- 
ticipating in voice communication during game play to 
avoid exposure to even mild profanity or verbal commu- 
nication with someone who might attempt to contact the 
child outside the scope of game play, for harmful pur- 
poses. The parental blocking of verbal communications 
of a child should be stored on the online game service 
and should still be in effect if the childe connects from a 
different game console. The prior art game voice com- 
munication systems do not permit blocking verbal com- 
munications by a selected player, such as a child, par- 
ticipating in games using a multiplayer game console. 
[0008] Another area of control of verbal communica- 
tions relates to the concept of policing the behavior of 
players. Ideally, the reactions of other players exposed 
to a specific player's behavior during verbal communi- 
cations while playing games on a network should be the 
basis for any prohibition placed on further verbal com- 
munication by that player. Should any player's verbal 
conduct be viewed as so egregious (based upon the 
number of complaints received from other players, or 
some other criteria) as to warrant it, an automated func- 
tion on the online game service or the online game serv- 
ice operator should be able to prevent that player from 
participating in verbal communication while playing 
games. The ban on verbal communication by such a 
player might only be for a limited period of time, e.g., for 
a period of a week, but, if justified by continued unac- 
ceptable verbal behavior, the ban on verbal communi- 
cation by the player might be made permanent. Again, 
the current voice communication systems do not enable 
this level of control to be applied to verbal communica- 
tion by selected players on a multiplayer game console 
who are connecting to other game consoles through an 
online game service service. 

Summary of the Invention 

[0009] As noted above, voice communication be- 
tween one person playing a game on a PC connected 
over a network to one or more other players who are 
each using their own PC to play the game is well known. 
However, the present invention pertains to multiplayer 
game consoles that enable verbal communication be- 
tween players who are playing the game on one or more 
game consoles. Specifically, the present invention ena- 
bles verbal communication by a specific player to be 
controlled during one or more games played on multi- 
player game consoles. To accomplish this function, data 
are maintained for each player participating in the game. 
The data include an indicator referencing a specific play- 
er who has been precluded from verbally communicat- 
ing during game play. The blocking of a player from ver- 
bally communicating applies during a current game ses- 
sion or during all games played with another player who 
has chosen not to verbally communicate with the spe- 
cific player, or during all games played by the specific 



player using an online game service service, or during 
all games played by the specific player using a specific 
multiplayer game console. In response to the indicator 
in the data and in accord with one of these criteria, verbal 
5 communication with the specific player is thus prevent- 
ed. N 

[0010] If the data include an association between the 
. other player who has chosen not to verbally communi- 
cate with the specific player and the indicator referenc- 

10 ing the specific player, the specific player will be pre- 
vented from verbally communicating with the other play- 
er in any game in which both the other player and the 
specific player are participating. To achieve this capa- 
bility, the data are maintained for each player in games 

is being played over the network and are accessed by the 
multiplayer game console. 

[001 1 ] It is also contemplated that the data can be cre- 
ated and maintained locally by a game being played on 
the multiplayer game console. In this case, the data will 
include an association between the other player who 
has chosen not to verbally communicate and the indi- 
cator referencing the specific player, so that the specific 
player will be prevented from verbally communicating 
with the other player during a game in which both the 

25 other player and the specific player are participants. 
[0012] Another type of verbal communication control 
is provided by enabling a parent or other authorized par- 
ty to select an option on the game console that deter- 
mines whether a minor child is able to participate in ver- 

30 bal communication while playing games. In this case, 
the indicator included in the data references the minor 
child as the specific player and indicate that the parent 
or authorized party has chosen to block verbal commu- 
nication in games played by the minor child. 

35 [0013] In most cases, the data that include the indica- 
tor are accessed at the online game service used for 
playing games over the network. Indeed, the indicator 
indicating that a specific player is precluded from ver- 
bally communicating can also be automatically created 

40 as a function of a number of complaints made by other 
players about the verbal communication behavior of the 
specific player. For example, if a specific player uses 
excessive profanity in verbal communications during 
game play so that a sufficient number of other players 

15 complain, the specific player can be automatically pre- 
vented from using voice communication for a defined 
lime interval, and, if the problem continues, the prohibi- 
tion can be made permanent. The player who has been 
prevented from verbally communicating cannot avoid 

so the problem simply by changing to a different alias or by 
using a different multiplayer game console. The indica- 
tor in the data refers to the specific player independently 
of any alias used by the specific player and without re- 
gard to the game console used by the specific player to 

55 piay a game over the network. 

[001 4] A player who has been precluded from verbally 
communicating with another player will not receive any 
indication that such a decision has been made. Thus, it 
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is not evident that a player has chosen not to communi- 
cate with another player. If a specific player has been 
generally precluded from verbally communicating in all 
games, the display will indicate to all other players in a 
game in which the specific player is participating, that 
the specific player has been muted. 
[0015] Verbal communication between players is 
preferably prioritized based upon user-define priorities. 
For example, a user may specify that verbal communi- 
cation with another player will always have priority, or 
game-specific roles assumed by players may be the ba- 
sis for setting the priority of a verbal communication rel- 
ative to other verba! communications. Thus, a verbal 
communication from a team leader may be set to have 
priority over verbal communications from other mem- 
bers of the team. The game may define the priorities, or 
the player may determine them. 

[0016] Another aspect of the present invention is di- 
rected to a memory medium having a plurality of ma- 
chine executable instructions for carrying out the steps 
of the method discussed above. Still another aspect of 
the invention is directed to a system for preventing ver- 
bal communication by a specific player during play of an 
electronic game The system includes a multiplayer 
game consolo having a processor, a network interface 
adaptod for communicating over a network with at least 
one other mui:ipUycr game console, verbal communi- 
cation input am cutput rtoviccs for each player who will 
be verbally communol ing during the game, and a 
memory in whicr arc stored machine instructions for 
causing the processor to carry out a plurality of func- 
tions. These functions are generally consistent with the 
steps of the method discussed above. 

Brief Description of the Drawing Figures 

[001 7] The foregoing aspects and many of the attend- 
ant advantages of this invention will become more read- 
ily appreciated as the same becomes better understood 
by reference to the following detailed description, when 
taken in conjunction with the accompanying drawings, 
wherein: 

FIGURE 1 is a schematic isometric view of a multi- 
player game console and voice communication sys- 
tem in accord with the present invention; 
FIGURE 2 is a block diagram of the multiplayer 
game console and voice communication module of 
FIGURED; 

FIGURE 3 is a functional block diagram of a multi- 
player game console with voice communication ca- 
pability; 

FIGURE 4 is a functional block diagram illustrating 
two multiplayer game consoles coupled in point-to- 
point communication over a network; 
FIGURE 5 is a block diagram illustrating a first mul- 
tiplayer game console coupled in communication 
with three other multiplayer game consoles over a 



network; 

FIGURE 6 is functional block diagram illustrating 
prioritization encoding for a plurality of players on a 
game console having two parallel encoders; 
s FIGURE 7 is a logic diagram illustrating the steps 
employed by the present invention in selecting 
packets from a queue to decode on a multiplayer 
game console; 

FIGURE 8 is a functional block diagram illustrating 
10 a Type 1 decoding engine u^ed in the multiplayer 
game console; 

FIGURE 9A is a functional block diagram illustrating 
a Type 2 decoding engine used in the -multiplayer 
game console; 
15 FIGURE 9B is a block diagram illustrating details of 
the mixers and 4-stream parallel decoder of FIG- 
URE 9 A; 

FIGURE 1 0 is a logic diagram illustrating further de- 
tails of the steps for transmitting and receiving en- 
20 coded packets of sound data over a network; 

FIGURE 11 is a functional block diagram showing 
how voice streams are received, queued, and de- 
coded for each player on a multiplayer game con- 
sole; 

25 FIGURE 12 is a flow chart illustrating the steps car- 
ried out for round robin encoding of sound packets; 
FIGURE 13 is an exemplary user interface for se- 
lecting voice options in a game that employs voice 
communication between players; and 

30 FIGURES 13A and 13B illustrate two different op- 
tions that are selectable by a player to control or 
preclude voice communication with another player 
in a multiplayer game, in accord with the present 
invention. 

35 

Description of the Preferred Embodiment 

Exemplary Gaming System for Practicing the Present 
Invention 

40 

[0018] As shown in FIGURE 1, an exemplary elec- 
tronic gaming system 1 00 includes a game console 1 02 
and support for up to four user input devices, such as 
controllers 104a and 104b. Game console 102 is 

^5 equipped with an internal hard disk drive (not shown in 
this Figure) and a portable media drive 1 06 that supports 
various forms of portable optical storage media, as rep- 
resented by an optical storage disc 108. Examples of 
suitable portable storage media include DVD discs and 

50 compact disk-read only memory (CD-ROM) discs. In 
this gaming system, game programs are preferably dis- 
tributed for use with the game console on DVD discs, 
but it is also contemplated that other storage media 
might instead be used, or that games and other pro- 

55 grams can be downloaded over the I nternet or other net- 
work. 

[0019] On a front face of game console 1 02 are four 
connectors 110 that are provided for electrically con- 
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necting to the controllers. It is contemplated that other 
types of connectors or wireless connections might alter- 
natively be employed. A power button 112 and a disc 
tray eject button 1 1 4 are also positioned on the front face 
of game console 102. Power button 112 controls appli- 
cation of electrical power to the game console, and eject 
button 114 alternately opens and closes a tray (not 
shown) of portable media drive 106 to enable insertion 
and extraction of storage disc 1 08 so that the digital data 
on it can be read and loaded into memory or stored on 
the hard drive for use by the game console. 
[0020] Game console 102 connects to a television or 
other display monitor or screen (not shown) via audio/ 
visual (A/V) interface cables 120. A power cable plug 
1 22 conveys electrical power to the game console when 
connected to a conventional alternating current line 
source (not shown). Game console 1 02 may be further 
provided with a data connector 124 to transfer data 
through an Ethernet connection to a network and/or the 
Internet, or through a broadband connection. Alterna- 
tively, it is contemplated that a modem (not shown) may 
be employed to transfer data to a network and/or the 
Internet. As yet a further alternative, the game console 
can be directly linked to another game console via an 
Ethernet cross-over cable (not shown). 
[0021] Each controller 104a and 104b is coupled to 
game console 1 02 via a lead (or in another contemplat- 
ed embodiment, alternatively, through a wireless inter- 
face) In the illustrated implementation, the controllers 
are Universal Serial Bus (USB) compatible and are con- 
nected to game console 1 02 via USB cables 1 30. Game 
console 1 02 may be equipped with any of a wide variety 
of user devices for interacting with and controlling the 
game software. As illustrated in FIGURE 1, each con- 
troller 104a and 104b is equipped with two thumb sticks 
1 32a and 1 32b, a D-pad 1 34, buttons 1 36, and two trig- 
gers 138. These controllers are merely representative, 
and other gaming input and control mechanisms may 
be substituted for or used in addition to those shown in 
FIGURE 1 , for controlling game console 102. 
[0022] Removable function units or modules can op- 
tionally be inserted into controllers 104 to provide addi- 
tional functionality. For example, a portable memory unit 
(not shown) enables users to store game parameters 
and port them for play on another game console by in- 
serting the portable memory unit into a controller on the 
other console. Other removable function units are avail- 
able for use with the controller. In connection with the 
present invention, a removable function unit comprising 
a voice communicator module 140 is employed to ena- 
ble a user to verbally communicate with other users lo- 
cally and/or over a network. Connected to voice com- 
municator module 1 40 is a headset 1 42, which prefera- 
bly includes a boom microphone 144 or other type of 
audio sensor that produces an input signal in response 
to incident sound, and an headphone 146 or other type 
of audio transducer for producing audible sound in re- 
sponse to an output signal from the game console. In 



another embodiment that is being contemplated (not 
shown), the voice communicator capability is included 
as an integral part of a controller (not shown) that is gen- 
erally like controllers 104a and 104b in other respects. 
5 The controllers illustrated in FIGURE 1 are configured 
to accommodate two removable function units or mod- 
ules, although more or fewer than two modules may in- 
stead be employed. 

[0023] Gaming system 100 is of course capable of 
10 playing games, but can also play music, and videos on 
CDs and DVDs. It is contemplated that other functions 
can be implemented by the game controller using digital 
data stored on the hard disk drive or read from optical 
storage disc 108 in drive 106, or from an online source, 
15 or from a function unit or module. 

Functional Components for Practicing the Present 
Invention 

20 [0024] Turning now to FIGURE 2, a functional block 
diagram illustrates, in an exemplary manner, how com- 
ponents are provided to facilitate voice or verbal com- 
munication between players during the play of electronic 
games on the multiplayer game console. As noted 

25 above, this embodiment of game console 1 00 can have 
up to four players on each console, and each player can 
be provided with a controller and voice communicator. 
Details of a voice communicator module 140' are illus- 
trated in connection with its associated controller 104a. 

30 it will be understood that controllers 104b, 104c, and 
104d (if coupled to game console 100) can optionally 
each include a corresponding voice communication 
module 140' like that coupled to controller 104a. In a 
current preferred embodiment, voice communication 

35 module 140' includes a digital signal processor (DSP) 
156, an analog-to-digital converter (ADC) 158, a digital- 
to-analog converter (DAC) 161 , and a universal serial 
bus (USB) interface 163. In response to sound in the 
environment that is incident upon it, microphone 144 

40 produces an analog output signal that is input to ADC 
1 58, which converts the analog signal into a correspond- 
ing digital signal. The digital signal from ADC 1 58 is input 
to DSP 1 56 for further processing, and the output of the 
DSP is applied to USB interface 163 for connection into 

45 controller 104a. In this embodiment, voice communica- 
tion module 140' connects into the functional unit or 
module port on controller 1 04a through a USB connec- 
tion (not separately shown). Similarly, digital sound data 
coming from game console 1 00 are conveyed through 

50 controller 1 04a and applied to USB interface 1 63, which 
conveys the digital signal to DSP 156 and onto DAC 
161. DAC 161 converts the digital signal into a corre- 
sponding analog signal that is used to drive headphone 
146. 

55 [0025] With reference to multiplayer game console 
100, several key functional components are shown, al- 
though it should be understood that other functional 
components relevant to the present invention are also 
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Included, but not shown. Specifically, game console 1 00 
includes a central processing unit (CPU) 1 50, a memory 
152 that includes both read only memory (ROM) and 
random access memory (RAM). Also provided is a DSP 
154. The digital signal produced by ADC 158 in re- 
sponse to the analog signal from microphone 1 44 is con- 
veyed through controller 104a to CPU 150, which han- 
dles encoding of the voice stream signal for transmis- 
sion to other local voice communication modules and to 
other game consoles over a broadband connection 
through an Ethernet port (not shown in FIGURE 2) on 
the game console. 

[0026] An alternative embodiment employs DSP 1 56 
in voice communication module 1 40' to encode the dig- 
ital signal produced by ADC 158 in response to the an- 
alog signal from microphone 1 44. The encoded data are 
then conveyed through controller 104a to CPU 150, 
which again handles transmission of the encoded data 
to other local voice communication modules and other 
game consoles over the broadband connection on the 
game console. 

[0027] It should be noted that multiplayer game con- 
sole 100 can be either directly connected to another 
game console using a crossover Ethernet cable as a 
link, or can be connected to one or more other multiplay- 
er game consoles through a more conventional network 
using a hub, switch, or other similar device, and/or can 
be connected to the Internet or other network through 
an appropriate cable modem, digital subscriber line 
(DSL) connection, or other appropriate interface broad- 
band connection. An alternative embodiment is also 
contemplated in which multiplayer game console 100 is 
connected to the Internet or other network through a mo- 
dem (not shown). Digital signals conveyed as packets 
over a direct or network connection are input to CPU 
1 50 through the Ethernet port on game console 1 00 (or 
from other voice communication modules and control- 
lers connected to the same game console), and are 
processed by the CPU to decode data packets to recov- 
er digital sound data that is applied to DSP 1 54 for output 
mixing. The signal from DSP 154 is conveyed to the in- 
tended voice communication module for the player who 
is the recipient of the voice communication for input 
through USB interface 163. 

[0028] An alternative embodiment employs the CPU 
to convey the encoded data packets to intended voice 
communication module 140' through controller 104a. 
The encoded data packets are then decoded by DSP 
156 in voice communication module 140', and the re- 
sulting decoded signal is conveyed to DAC 161, which 
creates a corresponding analog signal to drive head- 
phone 146. 

[0029] In still another contemplated alternative, the 
headphone and microphone for each player can be cou- 
pled directly to the game console and the functions of 
the voice communication module can be carried out by 
the CPU or other processor such as a DSP, and appro- 
priate DAC and ADC modules in the game console. The 



location of the components that process sound signals 
to produce sound data conveyed between players and 
to produce the analog signals that drive the headphone 
of each player is thus not critical to the present invention. 
5 [0030] CPU 1 50 also applies voice effects to alter the 
characteristics of the sound of a player speaking into 
microphone 144 and is able to change the character of 
the sound with a selection of different effects. For exam- 
ple, a female player can choose a voice effect to cause 
10 her voice to sound like the deep-Jone voice of a male, 
or so that the voice has an elfin quality, or so that it has 
one of several other desired different tonal and pitch 
characteristics. Available voice effects from, which a 
player can choose are game dependent. Such voice ef- 
15 fects can substantially alter the sound of the player's 
voice so that the player is virtually unrecognizable, and 
can add drama or greater realism to a character in a 
game being controlled by a player, when the character 
appears to speak to other characters in the game. The 
20 voice effects thus facilitate role playing and mask the 
player's true identity. Even when players connected to 
the same game console 1 00 are directly audible to each 
other because they are only a few feet apart in the room 
in which the game console is disposed, the change in a 
25 player's voice due to voice effects being applied so al- 
ters the sound heard by other players receiving the ver- 
bal communication through their headphones that the 
local sound of a player's voice propagating within the 
room to the players can easily be ignored. 
30 [0031 ] While not actually a limitation in the present in- 
vention, a current preferred embodiment of the game 
console 1 00 is designed with the expectation that a max- 
imum of up to 1 6 players can engage in verbal commu- 
nication during a game being played over a network or 
35 over the Internet through an online game service. Clear- 
ly, there is a practical limit to the number of verbal com- 
munications from other players with which a player 
might expect to engage at one time. Accordingly, it was 
assumed that a player is unable to comprehend verbal 
40 communications from more than four other players 
speaking simultaneously. 

Game Play Scenarios 

45 [0032] There are different appropriate scenarios, de- 
pending upon the type of game and the number of play- 
ers engaged in a given game that affect the require- 
ments for encoding and decoding voice communication 
signals. For example, there are three primary scenarios 

50 that impact on the requirements for voice communica- 
tion. The first scenario is referred to as "point-to-point" 
and includes one player on each of two interconnected 
game consoles, where each player is engaged in voice 
communication with the other player. In the second sce- 

55 nario, which is referred to as "multipoint," there is again 
only one player who is engaged in voice communication 
on each game console, but up to 16 game consoles are 
interconnected over a network for play of a game, in 
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which up to 16 players are participating. The third sce- 
nario is referred to as "multiplayer on game console," 
since up to four players per game console and up to four 
game consoles can be interconnected over a network 
to enable up to 1 6 players to simultaneously play a game 
and verbally communicate. In regard to the last scenar- 
io; two or more players on a single game console can 
also use voice communication during a game although 
they are physically located within the same room, since 
the benefits of the voice changes produced by use of 
the voice effects option can enhance the enjoyment of 
the game and role playing by each player, as noted 
above. Further, the limits of the total number of game 
consoles/player referenced above in each of the three 
scenarios can be thought of as soft limits, since there is 
no inherent hardware limitation precluding additional 
players or game consoles participating. 
[0033] By designing games in accord with one or 
more of these three scenarios, it is possible for the soft- 
ware designer to seta maximum predefined limit on the 
computing resources that will be allocated to voice com- 
munication, to avoid voice communication from ad- 
versely impacting the quality of game play. Also, a spe- 
cific game that is played on the multiplayer game con- 
sole can have its own requirements so that it is appro- 
priate for play by only a certain number of players. The 
nature of the game will then dictate limitations on the 
number of verbal communication channels required. For 
example, a game such as chess will normally be played 
using the point-to-point scenario, because chess typi- 
cally involves only two players. The voice communica- 
tion functionality enables the two players to talk to each 
other while playing a chess game. For this point-to-point 
scenario, each game console would need to instantiate 
only one encoder and one decoder, since more encod- 
ers and decoders are not required. During each voice 
frame update, the CPU on a game console will update 
any encoding and decoding as necessary. Using a pre- 
defined encode CPU usage limit of 1.5 percent and a 
decode CPU usage limit of 0.5 percent in the point-to- 
point scenario, the total requirement for CPU usage 
would be only about 2.0 percent. 
[0034] As shown in the functional block diagram of 
FIGU RE 4, a game console 1 02 is coupled in voice com- 
munication with a game console 172. Microphone 144 
responds to the voice of the player using console 102, 
and the voice communication module connected to the 
microphone produces pulse code modulated (PCM) da- 
ta that are input to a single stream encoder 160. In re- 
sponse to the PCM data, the encoder produces com- 
pressed data packets thfet are then transmitted over a 
network 1 70 to which game console 1 72 is connected. 
[0035] Alternatively, signal stream encoding can be 
carried out by the DSP of voice communication module. 
In this embodiment, microphone 144 responds to the 
voice of the player using game console 102, and DSP 
156 is connected to ADC 158 and produces the com- 
pressed data packets that are then sent to game con- 



sole 102 for transmission over network 170 to game 
console 172. 

[0036] The compressed data from game console 1 02 
are input to a network queue 1 74 in game console 1 02. 

5 The purpose of using a network queue to receive sound 
packet compressed data from console 1 02 is to remove 
jitter and other timing anomalies that occur when data 
are sent over network 170. The output of the single 
stream decoder is PCM data which are then applied to 

10 the DAC in the voice communication module of the play- 
er using game console 1 72 to produce an analog output 
that drives a headphone 178. 

[0037] In an alternative embodiment, the compressed 
data are conveyed from game console 102 to DSP 156 

'5 jn the voice communication module. The DSP decodes 
the compressed data, converting to a corresponding 
PCM signal, which is applied to DAC 161 in the voice 
communication module of the player using game con- 
sole 1 72, to produce a corresponding analog output sig- 

20 nal used to drive headphone 178. 

[0038]^ Similarly, for verbal communications from the 
player using console 172, a microphone 180 converts 
the sound incident on it into PCM data using the ADC 
within the communication module to which microphone 

25 1 80 is connected, and the PCM data are input to a single 
stream encoder 182, which produces compressed data 
that are conveyed through network 170 to a network 
queue 162 within game console 102. The compressed 
data from network queue 162 are input to a single 

30 stream decoder 1 68, which produces PCM data that are 
input to DAC converter in the voice communication mod- 
ule to which headphone 1 46 is connected. The DAC pro- 
duces a corresponding analog sound signal. Thus, 
headphone 146 receives the analog sound signal cor- 

35 responding to the sound of the player connected to con- 
sole 172 (with any voice effects added). 
[0039] In the multipoint scenario, where there is one 
player on each console, but multiple game consoles par- 
ticipating in a game session, the game designercan de- 

40 termine if all players should be able to verbally commu- 
nicate with all of the other players playing the game, or 
if there will be teams comprising subsets of the players, 
so that only the players in on the same team may talk 
to each other. For example, if the game being played in 

45 multipoint scenario Is a card game, there might be four 
individual players, one each per game console, or there 
might be two learns of two players each. If there are four 
separate players, each game console would instantiate 
one encoder and one four-to-one decoder (as discussed 

50 below). During a voice frame update, each console 
would update any encoding necessary for transmitting 
speech by the single player using the game console, 
and decoding of speech data from any of the (up to) 
three other players on the other game consoles partici- 

55 patinginthegame. For this scenario, using a predefined 
encode limit for CPU usage of 1 .5 percent and a four- 
to-one decoder limit for CPU usage of about 1 .3 percent, 
the total would be about 2.8 percent CPU usage on any 
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of the four game consoles being used to play the card 
game. 

[0040] FIGURES 3 illustrates how the multipoint sce- 
nario is functionally implemented on each game con- 
sole, but does not show the other game consoles. How- 5 
ever, it will be understood that network 170 couples the 
othergame consoles in communication with the illustrat- 
ed game console. As noted above, the game console 
includes a single stream encoder 160, which receives 
the PCM data produced by the ADC in the voice com- 
munication module (not shown in FIGURE 3) of the play- 
er. The PCM data are input into single stream encoder 
160, producing voice frames of compressed data in 
packet form for transmission over network 170 to the 
other game consoles. Similarly, packets of compressed 
data are conveyed through network 1 70 from the other 
game consoles to the illustrated game console. Each 
player participating in the game (or channel) has a net- 
work queue on the game console in which the data pack- 
ets are temporarily stored, to ensure that jitter and other 
timing problems are minimized when the packets of 
compressed data are selected by a selection engine 1 64 
for mixing by a mixer 1 66 and decoding by decoder 1 68. 
Decoder 1 68 produces PCM data that are supplied to 
tho DAC, which produces the analog signal that drives 
headphone 146. 

[0041 ] In an alternative embodiment, selection engine 
1 64 conveys the two selected compressed data streams 
to DSP 156 of the voice communication module (shown 
in FIGURE 2) for mixing and decompression. DSP 156 
produces a corresponding PCM signal that is supplied 
to the DAC in the voice communication module, which 
in turn, produces the corresponding analog signal that 
dnves headphone 146. 

[0042] As indicated in FIGURE 3, network queues 
1 62a. 1 62b, and 1 62c are respectively provided for each 
of the other players - up through N players. 
[0043] In the multipoint scenario discussed above, 
there are only three network queues., since there are on- 
ly three other players engaged in the card game. Since 
mixer 166 only combines two inputs at a time, decoder 
168 only can provide simultaneous PCM data for two 
players at a time to the player wearing headphone 146. 
In contrast, an alternative is also shown in which a de- 
coder 1 68' includes a mixer 1 66' that combines four data 
packets from a selection engine 164' at a time, to pro- 
duce the output provided to headphone 146. In this al- 
ternative, the player is provided up to four other voice 
data packets simultaneously. 

[0044] Alternatively, selection engine 1 64 can be em- 
ployed to convey four selected compressed data 
streams to DSP 156 in the voice communication module 
of an intended recipient. DSP 1 56 again produces a cor- 
responding PCM signal that is supplied to the DAC in 
the voice communication module, producing the corre- 
sponding analog signal to drive headphone 146. 
[0045] Functional details for the "multiplayer on game 
console" scenario are illustrated in FIGURE 5 where 



game console 1 02 is connected to network 1 70 through 
a network layer 206 and thus to a game console 210, 
having players 216a and 216b, to a game console 212 
having a single player 218, and to a game console 214 
having four players 220a, 220b, 220c, and 220d. Game 
console 102 has players 200a, 200b, 200c 5 and 200d 
connected thereto, and each player is provided with a 
game controller having a voice communication module. 
For this scenario, all of the players on each of consoles 
21 0,212, and 214 have voice communications that are 
encoded to produce single streams of compressed data 
packets. Network layer 206 in game console 102 con- 
veys the data packets from each of the three other game 
consoles into three separate network queues, including 
a network queue 162 for second game console 210, a 
network queue 184 for third game console 212, and a 
network queue 186 for fourth game console 214. The 
output from the three network queues in game console 
102 is input to decoder 168, and its output is applied to 
an output router 188 that determines the specific head- 
phone that receives voice communications 190a 
through 190d. 

[0046] An alternative embodiment employs output 
router 1 88 to bypass decoder 1 68 and pulls compressed 
data packets directly from network queues 162, 184, 
and 186. Output router 188 conveys the compressed 
data to the DSP in the voice communication module of 
the intended recipient, so that the headphone of that 
player receives voice communications 190a through 
190d. 

[0047] Accordingly, each of players 200a through 
200d receives only the voice communications intended 
for that player. Similarly, each of the four players on 
game console 1 02 has a sound input from their corre- 
sponding microphones 202a, 202b, 202c, and 202d 
supplied to an input router 204, which selectively applies 
the PCM data streams to encoder 160, which has an 
output coupled to network layer 206. The network layer 
ensures that the compressed data packets conveying 
sound data are transported over network 1 70 to the ap- 
propriate one of game consoles 210,212, and 21 4. The 
output router in each game console with multiple players 
determines the player(s) who will receive the voice com- 
munication from a player using game console 102. 
[0048] Another embodiment bypasses input router 
204 and encoder 1 60 by encoding the compressed data 
using the DSP in the voice communication module of 
the player who is speaking. 

Prioritization/Round Robin Technique for Encoding 

[0049] FIGURE 6 illustrates functional aspects re- 
garding prioritization on a game console handling voice 
communication by up to four players who are using the 
game console to play a game. During each voice inter- 
val, only two of four encoder instances are active, so 
that there are fewer encoders than there are players 
having voice communication capability, on the game 
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console. Thus, although there are four microphone 
211a, 211b, 211c, and 211d, the digital PCM data from 
the ADCs in the voice communication modules respec- 
tively connected to the microphones are not all encoded 
at the same time. Each stream of PCM data is applied 
to a voice activation detection algorithm, as indicated in 
blocks 213a, 213b, 213c, and 213d. This algorithm de- 
termines when a player is speaking into the microphone 
and producing PCM data that should be encoded for 
transmission to one or more other players in a game. In 
the worse case scenario, all four players might be 
speaking at the same time so that the voice activation 
detection algorithm would indicate that PCM data from 
all four microphones connected to the game console 
need to be encoded. However, since only two voice 
streams can be encoded at one time in this preferred 
embodiment, a prioritizing algorithm in a block 215 de- 
termines or selects the streams of PCM data that are 
input to the two parallel encoders 1 60'. These encoders 
produce compressed data in packetized frames that are 
conveyed over the network (assuming that the game 
console is connected to one or more other game con- 
soles over a link or network). In the example shown in 
FIGURE 6, the prioritizing algorithm has selected two 
streams of PCM data, including PCM data 21 7c and 
21 7d, as having the highest priority for encoding in the 
current frame for output over the network. In contrast, 
PCM data in streams 21 7a and 21 7b are marked as not 
having a voice input, but will have the highest priority for 
encoding in the next frame of compressed data if they 
then include voice data. 

[0050] A round-robin encoding method is used to en- 
able two parallel encoders to encode voice communica- 
tions from four players, so that fewer encoders are re- 
quired on the game console than the total number of 
players that may be speaking during any given voice da- 
ta frame. FIGURE 12 provides details concerning the 
logical steps that are implemented to enable round-rob- 
in encoding of a voice frame, beginning with a start block 
380. In a step 382, an array of the four PCM packets 
(one for each player) is assembled. In the case where 
a player does not have a voice communicator, a PCM 
silence packet is inserted into the array. A decision step 
384 determines if the logic is carrying out a first loop for 
the current voice frame. If so, a step 386 provides for 
preparing priorities in an array using the variable priority 
(i) where / can have the values 0, 1 , 2, or 3. Thereafter, 
the logic proceeds with a step 390. 
[0051 ] If the logic is not making a first loop for the cur- 
rent voice frame, it proceeds to a step 388, wherein the 
logic uses the priorities wrray that was generated in a 
previous loop for the current voice frame. Thereafter, the 
logic also proceeds to step 390. In step 390, the detec- 
tion of voice activation is carried out so that PCM pack- 
ets are marked to indicate whether they have voice con- 
tent. The algorithm detects whether the current sound 
level is substantially greater than an average (back- 
ground) level, which indicates that a player with a mi- 



crophone is probably currently speaking into it. Alterna- 
tively, the PCM packets can be analyzed to detect voice 
characteristics, which differ substantially from back- 
ground noise characteristics. A step 392 then initializes 

5 the variable priorities index as being equal to zero and 
a variable encodeops as being equal to zero. 
[0052] A decision step 394 determines if the priorities 
index variable is less than four and whether the enco- 
deops variable is less than two. Since decision step 394 

10 is initially reached immediately after step 392 in which 
these two variables have been initialized to zero, both 
these criteria are met, leading to a step 402. In step 402, 
a variable PCM stream indexls set equal to the variable 
priorities with a value / equal to the priorities index var- 

15 jable. In the initial pass for a voice frame, the PCM 
stream index variable is set equal to priorities [OJ. 
[0053] A decision step 404 then determines if voice 
has been detected for PCM packet with an index equal 
to the PCM stream index. Again, with the initial pass 

20 through this logic during a voice frame, the decision step 
determines if a voice was detected for PCM packet 
[PCM stream index]. If so, a step 406 moves the variable 
priorities [priorities index], which is at the end of the pri- 
orities array and shifts all other elements after it one 

25 place forward. A step 408 then sets the variable enco- 
deops equal to its previous value plus one, thereby in- 
crementing the variable. If voice was not detected in de- 
cision step 404, a step 41 0 sets priorities index equal to 
priorities index plus one, thereby incrementing that var- 

30 jable. Following either step 408 or step 410, the logic 
proceeds with decision step 394. 
[0054] Once the priorities index variable is equal to 
four or the encodeops variable is equal to two, the logic 
proceeds to a step 396. In this step, the logic sets the 

35 voice detected property for PCM packets [priorities [0]\ 
and PCM packets [priorities [1]\ on false. A step 398 
then provides for parallel encoding of PCM packet [pri- 
orities [2]\ and PCM packet [priorities [3]\. Finally, in a 
step 400, the logic assembles an array of four com- 

40 pressed data packets for transmission over the network 
for the current voice frame. Based upon this logic, it will 
be apparent that if all four players are actually speaking, 
PCM packets will be encoded to form the compressed 
packets using this round-robin algorithm so that all of 

45 the players on a voice console can communicate with 
other players in the game. 

[0055] It may be helpful to work through an example 
in which it is assumed that players one, two, three, and 
four are all talking at the same time. A history of the last 

so two voices or players that have been encoded is main- 
tained. The logic starts looking at the current micro- 
phone packet for player one. If a voice is detected by 
the algorithm, it is encoded. Next, the same determina- 
tion is made for player two, i.e., if a voice is present at 

55 player two's microphone, it is encoded in the current 
voice frame. The initial history starts out with the players 
ordered [1 , 2, 3, 4], but at this point, it is updated so that 
the order is players [3, 4, 1, 2]. The logic loops back, 
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after a predefined microphone encoding interval, to 
process the audio data for the two players that were not 
processed the last time. Currently the history list is [3, 
4, 1 , 2], so a check is made to determine if player three 
currently has voice input on his microphone, and if so, 5 
it is encoded. However, if player three is no longer talk- 
ing at this time, the logic instead proceeds to player four, 
who it is assumed is talking . Accordingly, the digital PCM 
voice packet for player four is encoded and the history, 
is updated to [3, 1 , 2, 4]. Next, the logic proceeds to play- 10 
er one, encoding that player's voice, producing a new 
history [3, 2, 4, 1]. The logic will then start with players 
three and two. Assuming that player three still is not 
speaking so that there is no voice at that player's micro- 
phone, the logic encodes the digital PCM packets for is 
players two and four, yielding a history list [3, 1 , 2, 4]. 
[0056] In one embodiment, for each PCM packet of a 
player that is skipped and not encoded, the previous 
packet for that player is attenuated and replayed for the 
voice frame. In the worst possible state, when all players 20 
are talking and there are actually four different players 
on the game console who are in different teams, every 
other PCM packet of each player is skipped. Although 
this approach may have a slight negative impact on the 
quality of the voice of each player, it is the worst case 25 
scenario, and this scenario typically occurs infrequently 
during game play. 

[0057] It should be noted that PCM packets of a player 
that are skipped and thus must be filled in by repeating 
the previous packet are not transmitted over the net- 30 
work. Instead, the repeated PCM packet is handled by 
the receiving game console used by the intended recip- 
ient of the packet. Accordingly, at most, two packets are 
sent from a game console during any one voice frame, 
instead of the maximum of four. The queue buffers the 35 
previous packet and provides it to replace a skipped 
packet. Alternatively, a skipped packet will not be put 
into the queue by the receiving game console, but in- 
stead, a notification indicating that the packet was 
skipped by the game console that made the transmis- 40 
sion will be inserted into the network queue of the re- 
ceiving game console, for that channel. 
[0058] The round-robin encoding technique only op- 
erates on two frames of speech at a time and repeats 
the other frames of those streams that are not currently 45 
encoded. As noted above, this can result in degradation 
of sound when all four players on a game console are 
speaking, but the technique avoids using additional 
CPU resources to separately encode the voices of all 
four players, which might have a negative impact on 50 
game play. 

[0059] In an alternative embodiment, one encoder per 
player is allocated for encoding speech. However, this 
embodiment is less desirable, because it requires twice 
the computational resources as the embodiment dis- 55 
cussed above. 



Voice Communication over Link/Network 

[0060] FIGURE 10 illustrates the general steps ap- 
plied for enabling voice communications over a link or 
network. Initially, a game is started in a step 330. Next, 
a decision step 332 determines if the player is stopped 
from communicating by voice with other players. This 
state may result because of the player being banned or 
suspended from voice communication by the online 
game service due to violations of % a code of conduct or 
other service policies. Another reason voice may be 
blocked is due to a determination by an authorized per- 
son such as a parent that a minor child should not be 
permitted to engage in voice communications with other 
players during a game. This option is available and can 
be set using options provided on the game console for 
specific player accounts. Once set, the data are stored 
on the online game service, and blockage of voice com- 
munication is enforced each time the player connects to 
the service. If the current player's voice communication 
is blocked, a step 334 determines that the game console 
need not process voice communications and instead, 
proceeds to a next speaker, in a step 336. Assuming 
that the next speaker is not precluded from having voice 
communication by a setting on the game console, the 
logic advances to a step 338, which gets the PCM data 
from the ADC in the voice communication module for 
that player. Next, the logic compresses the PCM speech 
data into compressed data in a step 340. A step 342 
applies any assigned voice effects when compressing 
the current player's PCM speech data to alter the char- 
acteristics of the player's voice. In a step 344, the com- 
pressed data are transmitted over a network 346 to an 
intended receiving game console to reach the intended 
recipients that have a voice communication module. A 
step 348 provides for processing the next speaker on 
the game console that is transmitting compressed data, 
thereby returning to decision step 332. 
[0061] On the game console that has received the 
voice communication over network 346, a step 352 pro- 
vides for adding the compressed data to a network 
queue of such data. Next, in a step 354, the game con- 
sole decompresses the compressed data pulled from 
the queue, producing corresponding PCM data. A step 
356 provides for adding any optional environmental ef- 
fects. Such effects are generally determined by options 
provided in a game being played on the game console. 
For example : an environmental effect might include 
adding an echo, or introducing a reverberation if the en- 
vironment of the game is within a cavern, or the envi- 
ronmental effect might involve providing a frequency 
band equalization, e.g., by adding a bass boost for play 
of the audio data on small speakers. Next, a step 358 
mixes voice streams received from a plurality of different 
players into one output voice stream that will be provid- 
ed to an intended recipient player. The output voice 
stream is conveyed as PCM data to the DAC associated 
with the headphone of the intended recipient player in 
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a step 360, which produces a corresponding analog sig- 
nal to drive the headphone. The player thus hears the 
voice communication from each of the players that were 
decoded and mixed into the output voice steam. 

Muted Voice Communication between Players 

[0062] Another situation arises whenever a specific 
player has been muted from voice communication by 
another player. Once a player has thus been muted, the 
specific muted player will be unable to either hear or 
speak with the muting player. The muting player must 
explicitly unmute the muted player to restore voice com- 
munication. 

Handling of Network Data Packets 

[0063] FIGURE 1 1 illustrates further details in regard 
to the receipt of voice communication data as packets 
over network 346. As indicated in block 351 a and 351 b, 
compressed data are received over the network from N 
other game consoles. Each channel of the compressed 
data is initially input into one of N queues 351a- 351b, 
where a separate queue is provided for each player on 
a connected game console (one or more players on 
each game console). A block 364 then synchronizes the 
N queues that have been formed to receive the com- 
pressed data. In this step, the encoded and compressed 
packets are obtained from all of the queues for a current 
voice frame. A selection engine 366 then determines the 
compressed packets that should be assembled for input 
to the decoding engine in a block 368. The decoding 
engine decompresses and decodes the compressed 
data, converting the data into PCM data that are then 
applied to each of the connected voice peripheral com- 
munications modules 370 through 372 to enable the 
players respectively using those voice communication 
modules to hear the sound that was transmitted over the 
network to them. 

[0064] Details relating to the processing of encoded 
packets that are received from each queue are shown 
in FIGURE 7. In a block 221, the CPU checks each 
queue to obtain an encoded compressed packet or the 
queue notifies the client CPU that it does not have a 
packet from a player, but that a packet for that player 
should have been in the queue. In this case, the CPU 
determines if the previous packet obtained for that play- 
er from the queue was in fact a valid encoded packet 
and if so, the CPU copies the previous packet for that 
player so it can be provided for further processing in the 
next block. However, if thje previous packet for that play- 
er was also missing, the CPU does an attenuation on 
previous packets for that player. The purpose of this step 
is to minimize the perception of silence caused by a 
missing packet resulting from skipping packets during 
round-robin encoding and from dropped packets due to 
network conditions. 

[0065] Next, in a block 222, the packets that have 



been obtained in block 221 are ordered, and all silent 
packets in the order are eliminated. The result is a sub- 
set of the packets originally provided in the queues. Due 
to the processing noted above, all packets in the subset 
will contain valid voice data. 

[0066] Next, a block 224 provides for applying chan- 
nel masks to the voice data. Each player is associated 
with a channel, and all players on a particular channel 
are able to communicate by voice with each other. For 
example, one channel may be used for voice communi- 
cation between a player who is designated as a team 
leader and team members, enabling that player to com- 
municate with all members of the team. In addition, the 
team leader may also be able to select another channel 
for verbal communication with another player designat- 
ed as a commander, who is able to communicate with a 
plurality of team leaders, or yet another channel to en- 
able the team leader to communicate only with the other 
team leaders. In this implementation, each player who 
is talking is given a 16-bit word that defines the "talker 
channel" for the player. The game determines what the 
individual bits of the word for the talker channel mean, 
e.g., indicating that the talker channel is for a team, a 
team leader, a commander, etc. In addition, each player 
can be assigned a "listener channel" on which they can 
receive speech. When a voice communication comes in 
overthe network, the talker channel is logically "ANDed" 
with the listener channel for a given player, and if the 
result is not zero, then that player is able to hear the 
voice communication. In this manner, the game being 
played (or each player, within the constraints of the 
game) is able to select arbitrary permutations that de- 
termine the players that are coupled in voice communi- 
cation with other players. 

[0067] Referring again to FIGURE 7, block 224 ena- 
bles each player to choose to listen to only some chan- 
nels and to employ a channel mask. A channel mask is 
applied for each player on the game console resulting 
in up to four subsets of voice streams - one subset for 
each player listening, based upon the player's individual 
listener mask. Each person who is listening will have a 
list of candidate packets included in different voice 
streams. 

[0068] In a block 226, the muting mask and user de- 
fined priorities are applied. While a preferred embodi- 
ment enables a player to selectively preclude further 
voice communications with a selected player, it is also 
contemplated that a player might selectively only mute 
voice communications with a specific player during a 
current game session. In this alternative embodiment, 
each player on a game console might choose to mute 
certain people on listening channels. Voice streams 
from players who have been muted by that player will 
then be eliminated from the list of candidate voice 
streams for that player on the game console. Any re- 
maining voice streams for each player are sorted by us- 
er-defined priorities. In this step, one voice stream may 
have the highest priority all the time. For example, the 
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game (or a player - if the game permits this option) may 
selectively set a channel coupling team member in voice 
communication with a team leader so that that channel 
has the highest priority for each of the team members. 
Loudness of the incoming voice stream can also be a 5 
basis for determining the priority of a channel for a given 
player, so that the player hears the loudest voice 
streams all of the time. Alternatively, or in addition, if a 
voice stream has started to render, the game will wait 
for it to finish regardless of the loudness of the other 
voice streams that started later so that a sentence is not 
cut off in "mid-stream," before it is finished. As a further 
alternative or in addition, other priorities can be defined 
for each voice channel. For example, a game-specific 
role related priority can be applied. 
[0069] Following block 226, decoding is applied to the 
voice streams resulting from applying the muting masks 
and user/game defined priorities using either a decoding 
engine type one as indicated in a block 228 or a decod- 
ing engine type two as indicated in a block 230. In block 
228, decoding engine type one allocates decoders, mix- 
ing and decoding for each player method. In this algo- 
rithm, for each player, the first N packets in a list of or- 
dered packets are selected. If the list contains less than 
N elements, silent compressed data packets used in- 
stead of the inexistent packets to avoid producing spikes 
in the CPU processing of the voice packets. 
[0070] In block 230, when applying decoding using 
engine type two, decoders are allocated for decoding 
and mixing in a DSP method. In accordance with this 
algorithm, until the maximum number of decoded pack- 
ets is reached, or the end of the candidate packet is 
reach, or the end of the candidate packet list is reached, 
the current player is obtained from the ordered list of 
packets, if the list is not empty. If the head of the list of 
ordered packets has not been chosen before, the head 
of the list is then chosen to be decoded and the counter 
is incremented for the decoded packets. Thereafter, the 
head of the list is eliminated from the ordered list. Next, 
the algorithm moves to the next player, who then be- 
comes the current player. For example, after player four, 
player one would then again become the current player. 
If any decoding slots remain for decoding additional 
voice packets, silence packets are applied to the parallel 
decoder to avoid spikes in CPU processing of the voice 
packets. 

Decoding Engines, Types One and Two 

[0071] In FIGURE 8, details relating to the functional 
aspects of decoding engine type one are illustrated. As 
shown therein, encoded streams from one through N 
designated by reference numerals 240, 242, and 244 
provide compressed data to a selection engine 257 that 
chooses two encoded streams for decoding for each 
player headphone. In this case, an encoded stream 1 .1 
and an encoded stream 1 .2 are selected for input to de- 
coder 1 68 where the streams are mixed by a mixer 252 



prior to decoding. The output of the decoder is PCM data 
that are supplied to the DAC within the voice communi- 
cation module for a headset 248. Similarly, for each of 
the other player headphones, another decoder 168 re- 
ceives encoded voice streams as compressed data, 
which are then mixed and decoded. As shown, the de- 
coder for a fourth player includes a mixer 254 that mixes 
encoded voice streams 4.1 and 4.2 so that the decoder 
produces PCM data that are supplied to the DAC that 
provides the analog signal to drive, a headphone 250 for 
the fourth player on the voice console. Of course there 
are instances where less than four players will be using 
a game console, in which case, fewer than four decod- 
ers are required to be active. 

[0072] An alternative embodiment to both decoding 
engine type 1 and decoding engine type 2 conveys the 
prioritized voice streams (at block 226) directly to the 
DSP in the voice communication module of the intended 
recipient. 

[0073] Functional aspects of the type two decoding 
engine are illustrated in FIGURE 9A. Again, encoded 
streams one through N represented by reference num- 
bers 240, 242, and 244 are input to a selection engine 
260, which chooses the maximum four encoder 
streams, a minimum of one for each player who is lis- 
tening and has a voice stream addressed to that player. 
In this case, four parallel decoders 262 receive the four 
selected encoded voice streams of compressed data. 
The decoders then decode the compressed data and 
supply the resulting PCM data to a mixerforeach player 
to whom any voice stream was intended. In this case, 
the first player receives two voice streams from other 
players that are mixed by a mixer 270 in a mixer identi- 
fied by reference number 264. Although not shown, 
each of the other players receiving voice communica- 
tions from other players in the game would also be pro- 
vided with a separate mixing bin to which the output of 
the four parallel decoders is applied for mixing. For ex- 
ample, the fourth player receives three voice streams 
that are mixed by a mixer 272 in a mixer identified by 
reference numeral 266. The resulting PCM data are 
then applied to headset 250 for the fourth player. Thus, 
each player can receive from one to four voice streams 
that are mixed by the four-in-one mixing bin assigned to 
that player. 

[0074] Another embodiment (at block 260) bypasses 
decoder 262 and mixers 264 and 266 and conveys the 
compressed data to the DSPs of the voice communica- 
tion modules coupled to headphones 248 and 250, re- 
spectively. 

[0075] An alternative approach for use in the type two 
decoding engine is illustrated in FIGURE 9B. In this em- 
bodiment, the relative disposition of the decoder and the 
mixers are reversed from that shown in FIGURE 9A. 
Specifically, each player is provided with a two-stream 
mixer that is coupled to receive and mix the compressed 
data incoming over the network. A two-stream mixer 280 
is provided for player one, a two-stream mixer 282 for 



75 



20 



25 



30 



35 



40 



45 



50 



12 



BNSDCCID: <EP 1362623A2J_> 



23 



EP 1 362 623 A2 



24 



player two, a two-stream mixer284 for player three, and 
a two-stream mixer 286 is provided for player four. Up 
to two voice streams of compressed data are thus Input 
to each of these mixers per player and are mixed, pro- 
viding a single mixed stream from each mixer for input 
to a four-stream parallel decoder 288. This decoder then 
decodes the compressed data producing PCM data that 
is supplied to each player headphone 248, 252, 253, 
and 250 who is an intended recipient of a voice commu- 
nication from another player. 

[0076] Yet another embodiment provides that the 
compressed data conveyed to two-steam mixers 28, 
282, 284, and 286 is decoded by the DSPs of the voice 
communication modules coupled respectively to head- 
phones 248, 252, 253, and 250. 

Controlling Voice Communication with Other Players 

[0077] As noted above, a player has the option of pre- 
cluding further voice communications with a specific 
player because of behavioral issues or for other rea- 
sons. For example, if a specific other player tends to us- 
es excessive profanity, a player may choose not to en- 
gage in further communications with that other player. 
Each game will generally provide an option for a player 
to mute voice communications with another player for 
the current and future game sessions, and it is also con- 
templated that a player might also be enabled to mute 
voice communications with another player for only a cur- 
rent game session. FIGURES 13, 13A, and 13B illus- 
trate exemplary dialog boxes that enable this control of 
voice communication to be implemented in a game 
called "MY GAME." This fictitious game lists each of the 
players, as shown in a player list box 430. Player list box 
430 includes six players of which the top listed player 
has been selected as indicated by a selection bar 434. 
This player, who plays the game using the alias "Aveng- 
er," has voice communications capability, as indicated 
by a speaker symbol 436 that is shown in one column 
of the dialog, in the same row as the alias. Players re- 
spectively using the aliases "Iceman" and "Raceox" do 
not have voice communication capability, as is evident 
by the lack of speaker symbol 436 in this column, in the 
same row as either of these aliases. A radio button 438 
is provided to enable any of the players listed to be mut- 
ed from voice communication with the current player 
who is viewing players list box 430. In this case, Avenger 
has been selected by the player, as Indicated by radio 
button 438. When the player is selected, a window 440 
opens that identifies the selected player and notes that 
this player is currently ^ne of the participants in the 
game and has a voice communication module. If the 
player viewing player's list box 430 clicks on a select 
button 442, a voice communication status select 450 
opens that includes an option bar 452, which can be tog- 
gled to different states. As shown in FIGURE 13A, op- 
tion bar 452 indicates that the selected player has been 
enabled to verbally communicate with the player who is 



selecting this option. In FIGURE 1 3B, the option bar has 
been toggled to a state 454, which indicates that the 
player viewing the state wants to mute the selected play- 
er for the current game session. Depending upon the 
5 selection that the player makes , speaker symbol 436 will 
change. Instead of that shown in FIGURE 1 3, if the play- 
er selected the option to mute the specific player has 
been chosen a dash box will appear around the speaker 
symbol shown. This type of muting expires afterthe cur- 
rent game session ends. On the other hand if the spe- 
cific player has been selectively locked out, a dash 
heavy-bar box will be added around speaker symbol 
436. In this case : the decision to mute a playe'r can only 
be turned off by the player making that decision from 
within a game session or using a system control for the 
game console. Yet another symbol (not shown) is used 
to indicate that voice communications for corresponding 
player are being played through loudspeakers (e.g., tel- 
evision or monitor speaker) connected to the game con- 
sole of the recipient player, rather than through a head- 
phone. This option can be selected by a player, who pre- 
fers not to wear a headset, but is less desirable, since 
the player will not be using a microphone to verbally 
communicate with other players. 

[0078] In the event that a number of players provide 
negative feedback concerning a specific player based 
upon the verbal behavior of that player being deemed 
to be unacceptable, such as excessive use of profanity, 
or use of sexually explicit language, the online game 
service can automatically determine that the number of 
complaints received has exceeded a threshold, causing 
the specific player to be banned from further voice com- 
munication. The ban might initially be for a limited period 
of time such as a week, and then subsequently, if further 
complaints are received beyond the threshold, the spe- 
cific player might be banned permanently from voice 
communication. A specific player that has been banned 
in this manner will be informed first of the temporary sus- 
pension of voice communication capability, and then of 
the permanent suspension, if the behavior of the player 
causes that result. Each time a player logs into the on- 
line game service on a game console, permission flags 
are downloaded to the game console as part of the sign 
in process. These flags include information about vari- 
ous aspects of the system. One of the flags determines 
whether a specific player has permission to engage in 
voice chat. Accordingly, in the event that a specific play- 
er violates the terms of service or code of conduct, the 
bit controlling the ability of the player to communicate 
by voice can be changed to preclude such voice com- 
munications. 

[0079] Once a player has elected to preclude voice 
communications with a specific player, the identification 
of the specific player is preferably transmitted to an on- 
line game service and stored there in relation to the iden- 
tity of the player making that election, so that in future 
sessions of any games, the player who has made such 
a decision will not receive any voice communication 
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from the specific other player and will not transmit any 
voice communication to the specific other player. This 
decision will not be apparent to the specific other player, 
since the dialog box showing the status of players in a 
game will simply display an indication on the specific 
other player's view that the player making that decision 
lacks voice communication capability, and in the dialog 
displayed to the player making the decision, the muted 
status of the specific other player will be indicated. Thus, 
even though the specific player changes the alias used 
or signs on with a different game console, the prohibition 
against voice communication for the specific player 
made by a player will continue in force. 
[0080] When participating in a game over the Internet 
or other network, a player may optionally, depending up- 
on the game being played, choose to play only with play- 
ers who agree to a specific language in which voice 
communications are to be conducted. Also, the player 
can optionally determine to play a game only with those 
players having voice communication capability. Similar- 
ly, players without voice communication capability may 
selectively play in games only with those other players 
who also do not have voice communication capability. 
Those decisions typically will apply only to a current 
game session. 

[0081] Although the present invention has been de- 
scribed in connection with the preferred form of practic- 
ing it and modifications thereto, those of ordinary skill in 
the art will understand that many other modifications can 
be made to the present invention within the scope of the 
claims that follow. Accordingly, it is not intended that the 
scope of the i nvention in any way be lim ited by the above 
description, but instead be determined entirely by refer- 
ence to the claims that follow. 



Claims 

1 . For use with an electronic game played on at least 
one multiplayer game console having a capability 
to provide verbal communication between players 
of games being played on said at least one multi- 
player game console, a method for preventing ver- 
bal communication by a specific player, comprising 
the steps of: 

(a) maintaining data for each player participat- 
ing in a game; 

(b) ihcluding an indicator in the data, said indi- 
cator referencing the specific player who is pre- 
cluded from verbally communicating during at 
least one of: 

s 

(i) a current game session played with an- 
other player who has chosen not to verbally 
communicate with the specific player; 

(ii) all games played with another player 
who has chosen not to verbally communi- 



cate with the specific player; 
(iii) all games played by the specific player 
over a network and using a specific online 
game service; and 
5 (iv) all games played by the specific player 

using any multiplayer game console; and 

(c) responding to the indicator in the data by 
automatically preventing verbal communica- 
w tion with the specific placer in accord with said 

at least one of subparagraphs (i) - (iv) of step 
(b). 

2. The method of Claim 1 , wherein the data include an 
*5 association between the other player who has cho- 
sen not to verbally communicate with the specific 
player and the indicator referencing the specific 
player, so that the specific player will be prevented 
from verbally communicating with the other player 

20 in any game in which both the other player and the 
specific player are participating. 

3. The method of Claim 2, wherein the data are main- 
tained for each player in a game that is played over 

25 the network that connects the players through the 
specific online game service, said data being ac- 
cessed by the multiplayer game console. 

4. The method of Claim 1 , wherein the data are creat- 
30 ed by a game being played on the multiplayer game 

console and include an association between the 
other player who has chosen not to verbally com- 
municate and the indicator referencing the specific 
player, so that the specific player will be prevented 
35 from verbally communicating with the other player 
during the game in which both the other player and 
the specific player are participating on the multiplay- 
er game console. 

40 5. The method of Claim 1 , further comprising the step 
of enabling a parent to select an option on the game 
console that determines whether a minor child of 
the parent is able to participate in verbal communi- 
cation while playing games, wherein the indicator 

45 included in the data references the minor child as 
the specific player and thereby indicates that the 
parent of the minor child has chosen to block verbal 
communication over the network by the minor child 
in games played by the minor child. 

50 

6. The method of Claim 1 , wherein the data that in- 
clude the indicator are accessed at the online game 
service used for playing games over the network. 

55 7. The method of Claim 1 , further comprising the step 
of automatically creating the indicator in the data in 
regard to the specific player, as a function of a 
number of complaints made by other players about 
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(b) verbal communication input and output de- 
vices for each player who will be verbally com- 
municating during the game, each verbal com- 
munication input and output device being 
5 adapted to connect to the multiplayer game 

console and including: 

(i) a sound sensor that produces an input 
signal indicative of sound incident on the 

*o sound sensor; and 

(ii) a sound transducer that produces an 
audible sound in response to an output sig- 
nal that is applied to the sound transducer; 



a behavior of the specific player. 

8. The method of Claim 7, wherein the data further in- 
clude an indication of a time interval during which 
the specific player will be prevented from verbally 
communicating during games played over the net- 
work through the specific online game service, said 
data being accessed by the multiplayer game con- 
sole when said specific player becomes a partici- 
pant in a game being played through the online 
game service. 

9. The method pf Claim 1 , wherein the indicator in the 
data refers to the specific player independently of 
any alias used by the specific player and without 
regard to a specific game console used by the spe- 
cific player to play a game over the network. 

10. The method of Claim 1, wherein during a game in 
which both the specific player and the other player 
who has chosen not to verbally communicate with 
the specific player are participating, further com- 
prising the step of displaying to the specific player 
an indication that the other player is unable to ver- 
bally communicalo 

11. The method of Clam 1 . wherein during a game in 
which both the specific player and the other player 
who has chosen not fo verbally communicate with 
the specific player arc participating, further com- 
prising the step of displaying to the other player an 
indication that the specific player has been muted. 

12. The method of Claim 1 . wherein if the specific player 
has been precluded from verbally communicating 
while partcipatmg in all games played over the net- 
work through the specific online game service, fur- 
ther comprising the step of indicating to all other 
players in a game in which the specific player is par- 
ticipating, that the specific player has been banned 
from verbally communicating over the network. 

13. A memory medium having a plurality of machine ex- 
ecutable instructions for carrying out the steps of 
Claim 1 . 

1 4. A system for preventing verbal communication by a 
specific player during play of an electronic game, 
comprising: 

i 

(a) a multiplayeigame console having a proc- 
essor, a network interface adapted for commu- 
nicating over a network with at least one other 
multiplayer game console, and a memory in 
which are stored machine instructions for caus- 
ing the processor to carry out a plurality of func- 
tions, said functions including executing an in- 
stance of a game; and 



(c) said machine instructions causing the proc- 
essor to preclude a specific player from verbally 
communicating during at least one of: 



(i) a current game session played with an- 
20 other player who has chosen not to verbally 

communicate with the specific player; 

(ii) all games played with another player 
who has chosen not to verbally communi- 
cate with the specific player; 

25 (iii) all games played by the specific player 

over a network and using a specific online 
game service; and 

(iv) all games played by the specific player 
using any multiplayer game console. 

30 

15. The system of Claim 14, wherein the machine in- 
structions cause the processor to identify the spe- 
cific player who is precluded from playing based up- 
on an indicator included in data that reference the 

35 specific player. 

16. The system of Claim 15, wherein the data include 
an association between the other player who has 
chosen not to verbally communicate with the spe- 

40 cif ic player and the indicator referencing the specific 
player, so that the processor of the multiplayer 
game console on which the other player is playing 
the game prevents the specific player from verbally 
communicating with the other player. 

45 

17. The system of Claim 15, wherein the machine in- 
structions that cause the processor to execute the 
instance of the game also cause the processor to 
maintain a record in the data for each player of the 

50 game, said record of the specific player including 
the indicator. 

18. The system of Claim 15, wherein the machine in- 
structions cause the processor to access the data 

55 at the specific online game service for each player 
participating in the game that is being played over 
the network. 
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19. The system of Claim 15, wherein the machine in- 
structions cause the processor to enable an author- 
ized party to select an option that determines 
whether a minor child is able to participate in verbal 
communication while playing games, said indicator 
included in the data referencing the minor child as 
the specific player to indicate that the authorized 
party has chosen to block verbal communication by 
the minor child over the network in games played 
by the minor child. 

20. The system of Claim 19, wherein the data that in- 
clude the indicator are accessed at the online game 
service used for playing a game over the network. 

21. The system of Claim 20, wherein the data further 
include an indication of a time interval during which 
the processor prevents the specific player from ver- 
bally communicating while playing games over the 
network through the specific online game service, 
said data being accessed by the processor of the 
multiplayer game console when said specific player 
becomes a participant in a game played over the 
network through the online game service. 

22. The system of Claim 1 5, wherein the indicator in the 
data references the specific player independently 
of any alias used by the specific player and without 
regard to the multiplayer game console that is used 
by the specific player to play the game over the net- 
work. 

23. The system of Claim 15, wherein during a game in 
which both the specific player and the other player 
who has chosen not to verbally communicate with 
the specific player are participating, said machine 
instructions cause the processor of the multiplayer 
game console used by the specific player to indicate 
to the specific player that the other player is unable 
to verbally communicate. 

24. The system of Claim 15, wherein during a game in 
which both the specific player and the other player 
who has chosen not to verbally communicate with 
the specific player are participating, said machine 
instructions cause the processor of the multiplayer 
game console used by the other player to indicate 
to the other player that the specific player has been 
muted. 

25. A method for controlling verbal communication be- 
tween players who play electronic games on at least 
one multiplayer game console that is generally ca- 
pable of supporting verbal communications be- 
tween players, comprising the steps of: 

(a) automatically identifying a specific player 
who is precluded from verbally communicating 



with at least one other player participating in an 
electronic game; and 

(b) in response to the identification of the spe- 
cific player, preventing the specific player from 
5 verbally communicating with said at least one 

other player during play of the electronic game 
on said at least one multiplayer game console. 

26. The method of Claim 25, wherein the step of auto- 
10 matically identifying the specific player comprises 

the step of accessing data that references the spe- 
cific player through an online game service service, 
by communicating over a network that is used for 
connecting a plurality of multiplayer game consoles 
is jn communication to play the electronic game. 

27. The method of Claim 25, further comprising the step 
of enabling a player to select the specific player to 
be precluded from verbally communicating from a 

20 |jst of players participating in the game with the play- 
er, the specific player who was thus selected there- 
after being precluded from verbally communicating 
with the player during any game in which the player 
and the specific player are both participating. 

25 

28. The method of Claim 25, further comprising the step 
of enabling a player to select the specific player to 
be precluded from verbally communicating from a 
list of players participating in the game with the play- 

30 er, the specific player who was thus selected there- 
after being precluded from verbally communicating 
with the player during a current electronic game 
session. 

35 29. The method of Claim 25, further comprising the step 
of automatically identifying the specific player as a 
function of a number of complaints about a behavior 
of the specific player by other players. 

40 30. The method of Claim 25, furthercomprisingthestep 
of enabling an authorized party to select an option 
on said at least one multiplayer game console that 
identifies a minor child as the specific party, to pre- 
vent the minor child from verbally communicating 

45 with any other players during any electronic game 
played by the minor child over a network. 

31. The method of Claim 25, further comprising the 
steps of saving the identification of the specific play- 

so er in data that are accessible at an online game 
service to said at least one multiplayer game con- 
sole, over a network. 

32. The method of Claim 31 , furthercomprising the step 
55 of including a time interval during which the specific 

party is precluded from verbally communicating 
while playing any game at the online game service 
over the network. 
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33. The method of Claim 25, further comprising the step 
of enabling user-defined priorities to determine if 
verbal communications with another player are 
heard by a player. 

5 

34. The method of Claim 33, wherein said user-defined 
priorities include at least one of: 

(a) a priority based upon specific game playing 
roles of players in a game; 10 

(b) a priority ensuring completion of a verbal 
communication from another player by avoid- 
ing interruption of said verbal communication 
with another verbal communication; 

(c) a priority determined by a relative loudness is 
of a verbal communication from another player; 
and 

(d) a priority determined by a game being 
played. 

20 
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